Content Management is an infrastructure to manage the full spectrum of digital information. Large collections of scanned images, facsimiles, electronic office documents, XML and HTML files, computer output, audio, video, multimedia, and virtual reality content can be stored and accessed through the content management system. The content management system integrates content with line of business, customer service, ERP, digital asset management, distance learning, Web content management or other applications to accelerate benefits across the enterprise.
In one embodiment the content manager product may be visualized as a triangle, its three vertices being the client, a library server and an object server (resource manager). The client is the user's interface which gives the user the capability of storing, searching for, and, marking-up documents (or to use the more general term, objects). The library server is the equivalent of a card catalog which holds information about the objects, including their location. The object server (OS), also referred to herein as the resource manager (RM) is where either the actual object or a pointer to the actual object is stored.
The core Library Server logic (except for system utilities and housekeeping tasks) is packaged as a set of relational data base (RDB) stored procedures (SPs) containing embedded SQL statements. Each stored procedure (SP) is precompiled and runs on a relational database (RDB) server. Thus each Library Server (LS) process is merely a relational database (RDB) server process. The interface to a Library Server is SQL, through which either stored procedures (SPs) can be called or SQL SELECT statements (including cursor support) can be executed. Remote access to Library Server is via a relational database (RDB) client.
The Resource Managers (RMs) may support different/multiple access protocols. The resource manager (RM)—object server (OS) supports the HTTP protocol. The basic information entities managed by the Library Server are “items.” “Items” as used herein come in two types, simple items and resource items. Resource items can have content associated with them that is stored in one or more Resource Managers. Resource items point to their content via Resource URL-RELATED DATA. One attribute of “items” is their “folder.”
The library server (LS) and object server (OS) (resource manager (RM)) are separate processes, often running on different machines. In operation, clients first contact the library server (LS) to create/update an index for an object, and to determine where the object is to be stored/replaced. The client then sends a request to the object server (OS) to store/replace the object.
To keep track of data entries, tens or hundreds attributes (parameters) may be defined to multiple databases and file systems in a database management system (DBMS). For example, a meaningful information entity may have multiple attributes associated with it. It is also frequently necessary to add, change, and delete the attributes associated with an information entity. This gives rise to problems in coordinating the backup of the multiple databases and file systems.
One approach to this problem is in the IBM Content Manager Version 8, which implements a single CM transaction involving the library server with two separate RDB transactions and data interchange with one or more resource managers. Specifically, the logic involved to implement a content manager transaction is:    1) Call the library server to “prepare” to store an object and commit the LS transaction.    2) Store the object on a resource manager, and commit the RM transaction.    3) Call the library server to store information about the object, and commit the LS transaction.    4) Send an “end transaction” request to the resource manager to finalize the changes and commit the RM transaction.
One problem arises because Step 2, storing the object on a resource manager, and committing the RM transaction, can require a variable amount of time depending, for example, on the size of the object and the network speed. Quiescing the workload is possible, but the fact that a CM transaction involves multiple RDB transactions means merely quiescing the workload does not help solve the coordination problem. There can be cases where the operation is initiated in step 1, calling the library server to “prepare” to store an object and commit the LS transaction, but by the time the library server is called to actually “store” information about the object, and commit the LS transaction, the requests would be rejected by the RDBMC.
Thus a further need exists to be able to “pause” the library server to enable coordinated backup of all servers, but without interrupting a transaction which is in progress.
A still further need exists to be able to consider the full CM transaction instead of the elemental LS and RM transactions, and to thereby reject new operations while allowing existing operations to complete.